Remarks 

In the Office Action mailed April 21, 2005: 

1. The spelling of the title was objected to; 

2. Claims 2, 3, 4, 5 and 7 were rejected under 35 U.S.C. § 112 11 2; and 

3. Claims 1-26 were rejected under 35 U.S.C. § 103(a) as being unpatentable over 
Admitted Art (AA) and U.S. Patent No. 5,812,767 (Desai), in further view of U.S. 
Patent Application Publication 2003/0110285 (Banerjee). 

I Title 

The title has been amended. 

II Rejections under 35 U.S.C. § 112 H 2 
Claims 2, 3, 4, 5 and 7 were amended. 



Ill Desai (U.S. Patent No. 5.812.767) 

Desai is directed to a system for address resolution to enable a data link provider 
interface to resolve address conflicts (title). 

Desai describes the operation of a network-connected DLPI (Data Link Provider 
Interface) with a driver capable of interfacing with a number of different protocols (column 1, 
lines 25-28). When the DLPI receives data from another network station, it determines what 
protocol is used, formats the data accordingly and forwards the data to a protocol module 
(column 1, lines 39-49). Similarly, when data are to be transmitted to another station, the DLPI 
recognizes the protocol being used and may format the data using an appropriate address 
resolution routine (column 1, lines 50-59). Thus, Desai focuses on what the DLPI does in order 
to receive or transmit data from/to a network. 

Desai does not teach or suggest all relevant aspects of Applicant's invention. 

A. Desai Does Not Receive from a Data Link User a Request to Identify a 
Communication Protocol Supported by a Data Link Provider 

In Applicant's present application, a data link user, which uses the services of a DLPI, is 

adapted to process communications received through a DLPI. The data link user (e.g., a snoop 

utility) needs to know the format of a communication protocol according to which a 
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communication is formatted, in order to process that communication. Therefore, it may query 
the DLPI to identify the protocol defining a communication given to the data link user by the 
DLPL 

In contrast, the DLPI in Desai is not queried as to what communication protocol(s) it does 
or will use, and certainly does not receive such a query from a data link user. The DLPI merely 
processes communications according to their protocols; Desai says nothing about identifying 
those protocols. 

Just because a DLPI in Desai can communicate with network stations using different 
communication protocols (column 1, lines 25-28; column 1, lines 60-63) does not mean that the 
DLPI is asked what communication protocols it handles. It simply processes data according to 
the appropriate protocol, and therefore need not and does not care whether a data link user knows 
what communication protocol is in use . 

And, Desai only appears concerned with network-side operations (i.e., receiving data 
from or sending data to a network). Because Desai is not concerned with the operations of data 
link users, it would not be referred to by anyone attempting to interact between data link users 
and data link providers. 

IV Baneriee (U.S. Patent Application Publication No. 2003/0110285) 

Banerjee is directed to the generation of an XML document to represent an exchange of 
network protocol packets (Abstract; Summary), and does not teach or suggest all relevant aspects 
of Applicant's invention. 

A. Banerjee Does Not Enable a Data Link User to Parse a Communication 
Protocol 

In embodiments of Applicant's invention, in response to its request for the identity of a 
communication protocol, a data link user is enabled to parse the protocol. The portions of 
Banerjee cited in the rejection of claim 1 describe the goal of generating an XML document to 
represent network protocol packet exchanges (page 3 [0043]), and the use of such a document to 
investigate network communication problems (page 5 [0071]). 

The Examiner stated that "Banerjee does teach enabling a data link user to parse a 
communication packet" (office action, page 4, bottom paragraph). Applicant disagrees. 

First, it is assumed that the Examiner is equating Banerjee's XML parser with 
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Applicant's data link user. In particular, in the 3 rd paragraph of page 5 of the office action, the 
Examiner states that "Banerjee does teach sending a data link user an XML (Extensible Markup 
language) document describing communication protocol format". 

However, Banerjee's XML parser apparently just determines "whether the TCP/IP 
connection sequence was proper" (page 5 [0078]) or "whether the close setup connection was 
successful" (page 6 [0084]). To do so, the parser does not parse a protocol; it merely looks for a 
particular sequence of events in an XML document. As Banerjee specifies, the XML document 
"represents network protocol packet exchanges" (e.g., page 1 [0010]; emphasis added), not 
actual packets. The parser parses descriptions of communication events, not packets. See 
Figures 11, 15, 17 of Banerjee. 

Thus, the XML parser of Banerjee may be able to look for specific text in an XML 
document, but it does not know how to parse a communication protocol . Even if it does have 
this knowledge, it is not enabled to do so by the entity that generated the XML document, and 
was not enabled in response to a request for an identify of a communication protocol. 

Second, if it is the entity that generates the XML document in Banerjee that is being 
equated with Applicant's data link user, that entity must already know how to parse the 
communication protocol. There is no suggestion that the entity is taught how to parse the 
protocol to generate the document. In particular, Banerjee specifies that " Knowing the 
connection establishment, the transition state of each user data packet and the close connection 
procedures of TCP ... a software program may be written to convert TCP data transactions into 
an XML document" (page 5 [0071]; emphasis added), indicating that the "ability" to parse the 
protocol is hard-wired. 

Thus, Banerjee may describe generating an XML document from TCP data transactions, 
but there is no description of teaching or enabling anything to parse a communication protocol, 
especially not in response to a request to identify a communication protocol . 

Further, because Banerjee is hard-wired to work with one specific protocol (i.e., TCP), 
there is no need to learn or be enabled to parse another protocol, and one skilled in the art 
looking for a way to enable a data link user to parse an unknown protocol would not look to 
Banerjee . Banerjee thus teaches away from Applicant's invention. 
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V Selected Claims 

A. Claims 1-6 

Claims 1 and 6 

Claims 1 and 6 specify that a data link provider receives a request to identify a 
communication protocol supported by the provider. These claims were amended to make it 
clearer that, in this embodiment of the invention the request is received from the data link user. 
As described above in Section III.A, Desai does not teach receiving a request to identify a 
protocol supported by a data link provider. 

Claims 1 and 6 also recite "in response to said second request, enabling the data link 
provider to parse the communication protocol." As discussed in Section IV.A, Banerjee 
describes the generation of an XML document from TCP packet exchanges and the parsing of 
the document to investigate network communication problems. But, there is no mention of 
enabling anything to parse a protocol, because the entity that generates the XML document 
already knows how to do so, and the XML parser does not need such knowledge and is not 
enabled to do so. See Figures 11, 15, 17 of Banerjee. 

Claim 3 

Claim 3 recites "sending the data link user an XML (Extensible Markup Language) 
document describing a format of the communication protocol". As described in Section IV.A, 
Banerjee does not send a data link user an XML document describing communication protocol 
format. Banerjee sends an XML parser an XML document describing exchanges of packets . 
Describing what packets were exchanged is very different from describing the actual structure of 
one of those packets. 

B. Claims 7-12 

Claims 7 and 12 

Claims 7 and 12 specify that a data link user requests a data link provider to identify a 
communication protocol supported by the provider. As described above in Section III.A, Desai 
does not teach receiving a request to identify a protocol supported by a data link provider. 

Claims 7 and 12 also recite "receiving a description of the format of the communication 
protocol from the data link provider." Claims 7 and 12 were amended to make it clearer that, in 
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this embodiment of the invention, it is the data link user that receives the description. As 
discussed in Section IV.A above, Banerjee describes the generation of an XML document from 
TCP packet exchanges, and the parsing of the document to investigate network communication 
problems. But, the data link user (e.g., the XML parser) does not receive a description of the 
format of a protocol; it receives a description of an exchange of packets. It therefore does not 
need to parse a protocol and is not enabled to do so. See Figures 11, 15, 17 of Banerjee. 

Claim 9 

Claim 9 recites "receiving at the data link user an XML (Extensible Markup Language) 
document describing said format" (of the communication protocol). As described in Section 
IV.A, Banerjee does not send a data link user an XML document describing communication 
protocol format. Banerjee sends an XML parser an XML document describing exchanges of 
packets . Describing what packets were exchanged cannot be compared with describing the 
actual structure of one of those packets. 

C. Claims 13-19 

Claims 13 and 19 

Claims 13 and 19 specify that a data link user requests a data link provider to identify a 
communication protocol supported by the provider. As described above in Section III.A, Desai 
does not teach receiving a request to identify a protocol supported by a data link provider. 

Claims 13 and 19 also specify that the data link user is sent a response enabling it to parse 
the protocol. As discussed in Section IV.A above, Banerjee describes the generation of an XML 
document from TCP packet exchanges, and the parsing of the document to investigate network 
communication problems. But, the data link user (e.g., the XML parser) in Banerjee does not 
receive a description of the format of a protocol; it receives a description of an exchange of 
packets. It therefore does not need to parse a protocol and is not enabled to do so. See Figures 
11, 15, 17 of Banerjee. 

Claim 15 

Claim 15 recites "wherein said second response comprises an XML (Extensible Markup 
Language) document describing a format of the communication protocol." As described in 
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Section IV.A, Banerjee does not send a data link user an XML document describing 
communication protocol format. Banerjee sends an XML parser an XML document describing 
exchanges of packets . Describing what packets were exchanged cannot be compared with 
describing the actual structure of one of those packets. 

D. Claims 20-26 

Claim 20 

Claim 20 specifies that a data link user requests a data link provider to identify a 
communication protocol supported by the provider. As described above in Section III.A, Desai 
does not teach receiving a request to identify a protocol supported by a data link provider. 

Claim 20 also specifies that the data link user is offered information enabling it to parse 
the protocol. As discussed in Section IV.A above, Banerjee describes the generation of an XML 
document from TCP packet exchanges, and the parsing of the document to investigate network 
communication problems. But, the data link user (e.g., the XML parser) does not receive a 
description of the format of a protocol; it receives a description of an exchange of packets. It 
therefore does not need to parse a protocol and is not enabled to do so. See Figures 11, 15, 17 of 
Banerjee. 

Claim 23 

Claim 23 recites "wherein said information ... comprises an XML (Extensible Markup 
Language) document describing a format of the communication protocol." As described in 
Section IV.A, Banerjee does not send a data link user an XML document describing 
communication protocol format. Banerjee sends an XML parser an XML document describing 
exchanges of packets . Describing what packets were exchanged is far different from describing 
the actual structure of one of those packets. 

Claim 26 

Claim 26 specifies that the data link provider enables the data link user to access, on the 
data link provider, processor executable instructions for parsing the protocol. Banerjee does not 
do this. As described in Section IV.A, Banerjee sends an XML parser an XML document 
describing exchanges of packets. Even if the XML parser can be considered "processor 
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executable instructions," in Banerjee those "instructions" are sent to the XML parser . They are 
not accessed on a data link provider. 



CONCLUSION 



No new matter has been added with the preceding amendments. It is submitted that the 
application is in suitable condition for allowance. Such action is respectfully requested. If 
prosecution of this application may be facilitated through a telephone interview, the Examiner is 
invited to contact Applicant's attorney identified below. 



Park, Vaughan & Fleming LLP 

39180 Liberty Street, Suite 103 
Fremont, CA 94538 
(510) 790-9960: voice 
(510) 790-9964: facsimile 



Respectfully submitted, 
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